Grant the Keyfactor Command Users and Service Account(s) Permissions on the CAs

In order for Keyfactor Command to be able to synchronize certificates from the CAs to the Keyfactor Command database, the service account under which Keyfactor Command makes a connection to the CAClosed A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA. must have permissions to read the CA databases. For full Keyfactor Command functionality, additional permissions are needed. The permissions needed vary depending on the type of CA and the type of authorization you intend to configure to allow Keyfactor Command and users in Keyfactor Command to interact with the CA.

Microsoft CAs

When you configure Keyfactor Command access to a Microsoft CA, you have the option to enable the Use Explicit Credentials option. When this option is enabled, you enter a set of credentials that will be used specifically to access that Microsoft CA, and all management and enrollmentClosed Certificate enrollment refers to the process by which a user requests a digital certificate. The user must submit the request to a certificate authority (CA). tasks for that CA are done in the context of that service account. If you do not enable the Use Explicit Credentials option, management tasks (e.g. revocation, certificate synchronization) and enrollments are done in the context of the service account(s) you configure for the Keyfactor Command Service and Keyfactor APIClosed A set of functions to allow creation of applications. Keyfactor offers the Keyfactor API, which allows third-party software to integrate with the advanced certificate enrollment and management features of Keyfactor Command. the application pool for Keyfactor Command (which are the same service account in many implementations) and individual users. The exact combination of what happens in the context of who depends on the configuration of the delegation options (Delegate Management Operations and Delegate Enrollment) on the CA when the Use Explicit Credentials option is not enabled. Delegation is supported for Basic and Kerberos authentication (see Configure Kerberos Constrained Delegation (Optional)) but not NTLM or Token authentication. Use of explicit credentials is mutually exclusive of delegation.

The users and service account(s) you will be using to connect to your Microsoft CA(s) from Keyfactor Command need some set of the following permissions on the CA, based on the configuration of authorization for the CA:

Table 858: Microsoft CA Permission Matrix provides information on what permissions are required on the Microsoft CA based on possible authorization configurations.

In the management console for each CA that Keyfactor Command will be interacting with, open the properties for the CA and grant the users and service account(s) for Keyfactor Command the appropriate permissions for your environment before continuing.

Table 858: Microsoft CA Permission Matrix

  Use Explicit Credentials

Use Explicit Credentials

Delegate Management

Delegate Enrollment

Use Explicit Credentials

Delegate Management

Delegate Enrollment

Use Explicit Credentials

Delegate Management

Delegate Enrollment

Use Explicit Credentials

Delegate Management

Delegate Enrollment

Explicit CA-Specific User

Read

Issue & Manage Certs

Manage CA

Request Certs

n/a n/a n/a n/a
Keyfactor Command Service Account None

Read

Request Certs1

Read

Request Certs2

Read

Request Certs3

Read

Request Certs4

Keyfactor API Application Pool Account5

None

Read

Issue & Manage Certs

Manage CA

Request Certs6

Read

Issue & Manage Certs

Manage CA

Request Certs7

Read

Manage CA

Request Certs

Read

Issue & Manage Certs

Manage CA

Request Certs

Individual Users None

Read

Issue & Manage Certs

Request Certs

Read

Request Certs

Read

Issue & Manage Certs

None
EJBCA CAs

Management (e.g. revocation, certificate synchronization) and enrollment requests to an EJBCA CA are made in the context of the end entity associated with the client certificate selected in each CA configuration in the Keyfactor Command Management Portal to provide authentication to the EJBCA CA (see Acquire a Client Certificate for EJBCA CA Authentication). The access rule created or used for this needs to grant sufficient permissions to allow the end entity to synchronize certificates. For full functionality, it needs the following permissions:

  • /administrator/

    To support Keyfactor Command making API requests to the EJBCA CA

  • /ca/[your_ca_name]/

    To support Keyfactor Command access to your CA

  • /ca_functionality/create_certificate/

    To support certificate enrollment through Keyfactor Command

  • /ca_functionality/create_crl/

    To support CRL publication following revocation

  • /ca_functionality/view_ca/

    To support retrieval of CA information

  • /ca_functionality/view_certificate/

    To support CA synchronization

  • /ca_functionality/view_certificate_profiles/

    To support templateClosed A certificate template defines the policies and rules that a CA uses when a request for a certificate is received. import

  • /endentityprofilesrules/[your_end_entity_profile_name]/create_end_entity/

    To support creation of end entities (a new end entity is created for each Keyfactor Command certificate enrollment unless the Enforce Unique DN option is enabled and the new certificate's DNClosed A distinguished name (DN) is the name that uniquely identifies an object in a directory. In the context of Keyfactor Command, this directory is generally Active Directory. A DN is made up of attribute=value pairs, separated by commas. Any of the attributes defined in the directory schema can be used to make up a DN. matches that of an existing certificate)

  • /endentityprofilesrules/[your_end_entity_profile_name]/edit_end_entity/

    To support certificate enrollment with the Enforce Unique DN option through Keyfactor Command and certificate renewal through Keyfactor Command

  • /endentityprofilesrules/[your_end_entity_profile_name]/revoke_end_entity/

    To support certificate revocation through Keyfactor Command

  • /endentityprofilesrules/[your_end_entity_profile_name]/view_end_entity/

    To support certificate enrollment through Keyfactor Command

  • /ra_functionality/create_end_entity

    To support creation of end entities (a new end entity is created for each Keyfactor Command certificate enrollment unless the Enforce Unique DN option is enabled and the new certificate's DN matches that of an existing certificate)

  • /ra_functionality/edit_end_entity

    To support certificate enrollment with the Enforce Unique DN option through Keyfactor Command and certificate renewal through Keyfactor Command

  • /ra_functionality/revoke_end_entity

    To support certificate revocation through Keyfactor Command

  • /ra_functionality/view_end_entity

    To support certificate enrollment through Keyfactor Command

  • /system_functionality/view_administrator_privileges

    To support overall functionality

Figure 534: EJBCA Access Permissions

You may either create a new access rule that limits access to just these required permissions, or use an existing access rule. In either case, you need to add the certificate used to authenticate Keyfactor Command to the EJBCA CA as a member of that access rule.

Figure 535: Add Client Certificate as Member of EJBCA Access Rule